set this as a draft until solve the docker base image.

@sebastianwebber thanks for putting this together. This all LGTM, but I've practically zero knowledge of goreleaser so definitley want other eyes here. @xyphr or @m86194 thoughts?

I'd also add the changes to the CI. @cevich and @edsantiago any goreleaser experience?

@sebastianwebber thanks for putting this together. This all LGTM, but I've practically zero knowledge of goreleaser so definitley want other eyes here. @xyphr or @m86194 thoughts?

No worries.

I case that you want to try it, just run:

goreleaser --snapshot --skip-publish --rm-dist

the output should be something like this:

➜ goreleaser --snapshot --skip-publish --rm-dist
   • releasing...     
   • loading config file       file=.goreleaser.yml
   • running before hooks
   • loading environment variables
   • getting and validating git state
      • releasing v1.1.0, commit c55d7cf38b63c9829b6353412b985d65f9c77478
      • pipe skipped              error=disabled during snapshot mode
   • parsing tag      
   • setting defaults 
      • snapshotting     
      • github/gitlab/gitea releases
      • project name     
      • building binaries
      • creating source archive
      • archives         
      • linux packages   
      • snapcraft packages
      • calculating checksums
      • signing artifacts
      • docker images    
      • artifactory      
      • blobs            
      • homebrew tap formula
      • scoop manifests  
      • milestones       
   • snapshotting     
   • checking ./dist  
      • --rm-dist is set, cleaning it up
   • writing effective config file
      • writing                   config=dist/config.yaml
   • generating changelog
      • pipe skipped              error=not available for snapshots
   • building binaries
      • building                  binary=/home/seba/projetos/pessoal/skopeo/dist/linux_linux_amd64/skopeo
   • archives         
      • creating                  archive=dist/skopeo_v1.1.0-next_Linux_x86_64.tar.gz
   • creating source archive
      • creating source archive   file=skopeo-v1.1.0-next.tar.gz
   • linux packages   
      • creating                  file=dist/skopeo_v1.1.0-next_linux_amd64.deb
      • creating                  file=dist/skopeo_v1.1.0-next_linux_amd64.rpm
   • snapcraft packages
   • calculating checksums
      • checksumming              file=skopeo_v1.1.0-next_linux_amd64.rpm
      • checksumming              file=skopeo_v1.1.0-next_Linux_x86_64.tar.gz
      • checksumming              file=skopeo-v1.1.0-next.tar.gz
      • checksumming              file=skopeo_v1.1.0-next_linux_amd64.deb
   • signing artifacts
   • docker images    
      • building docker image     image=containers/skopeo:v1.1.0
      • pipe skipped              error=publishing is disabled
   • publishing       
      • blobs            
         • pipe skipped              error=blobs section is not configured
      • http upload      
         • pipe skipped              error=uploads section is not configured
      • custom publisher 
         • pipe skipped              error=publishers section is not configured
      • artifactory      
         • pipe skipped              error=artifactory section is not configured
      • docker images    
         • pipe skipped              error=publishing is disabled
      • snapcraft packages
         • pipe skipped              error=publishing is disabled
      • github/gitlab/gitea releases
         • pipe skipped              error=publishing is disabled
      • homebrew tap formula
         • token type                type=github
      • scoop manifests  
         • pipe skipped              error=publishing is disabled
      • milestones       
         • pipe skipped              error=publishing is disabled
   • release succeeded after 8.25s

Please note that there is some limitations to cross-compiling since we have a few C dependencies. I'm not sure if it will be possible to generate OSX binaries or generate a 32 bits version. If 32bits is mandatory please let me know.

the CI. @cevich and @edsantiago any goreleaser experience?

None whatsoever, don't even know how to spell it. Though I appreciate the heads up given the significance of the feature.

I don't remember the state of CI on this repo., @sebastianwebber what were you thinking in terms of updating it?

Any thoughts on publishing the outputs? I have a good handle on most of the security-models involved. I'll help with providing tokens or credentials as needed, if that's helpful.

the CI. @cevich and @edsantiago any goreleaser experience?

None whatsoever, don't even know how to spell it. Though I appreciate the heads up given the significance of the feature.

I don't remember the state of CI on this repo., @sebastianwebber what were you thinking in terms of updating it?

I can do that, even fix the current docker image, and integrate with the current build with Travis CI.

Any thoughts on publishing the outputs? I have a good handle on most of the security-models involved. I'll help with providing tokens or credentials as needed, if that's helpful.

I think that, for now, set the builds on the release page will be a nice start.

I will extend the changes to support this and get back to you.

Fantastic! Really happy to see things modernize here. Please let me know if you need help with anything.

I would prefer commends use "container image" rather then "docker image"...

Hi. Thanks for the work!

The original conversation in #715 was centered around Windows support, where we have little expertise and any way to release binaries would help.

As for Linux builds, I’m not quite sure that introducing a tool that apparently few people understand, and moving the burden of maintaining them to this project, makes that much sense.

• It would be confusing to publish two sets of “official” container images, both this and https://github.com/containers/skopeo/tree/master/contrib/skopeoimage — and probably rather different ones right now.
• Linux distribution packages are probably best maintained as parts of the distribution, by someone who understands the distribution, the standards and conventions, and how to best adjust/integrate the software. A package resulting from just running make here would be rather different from https://src.fedoraproject.org/rpms/skopeo/blob/master/f/skopeo.spec , or the strongly unbundled https://salsa.debian.org/go-team/packages/skopeo . A separate Fedora/Debian packaging maintained in this repository would probably not be kept up-to-date with best practices.

Of course, we all can learn new tools; but the above concerns are not very tooling-related.

@TomSweeneyRedHat could there be a benefit for building the “unstable” image? I can’t remember how, and how frequently, that one is being built now.

@mtrmac I think your "unstable" image is our "upstream" image (quay.io/skopeo/upstream:latest). We build that along with quay.io/skopeo/stable:latest and quay.io/skopeo/testing:latest once a day, assuming the cron process that I've set up doesn't have failures. Currently, that's configured to fire off at 9:00 a.m. Eastern every day. The Dockerfiles that run those live here fwiw.

Hey all, sorry for the delay.

The original conversation in #715 was centered around Windows support, where we have little expertise, and any way to release binaries would help.

Since the code has some C dependencies, like libdevmapper1 and CGO I'm not sure it will be possible to use go-releaser to cross-build windows binaries. There is a note about that on its docs: https://goreleaser.com/limitations/cgo/

As for Linux builds, I’m not quite sure that introducing a tool that apparently few people understand, and moving the burden of maintaining them to this project, makes that much sense.

That depends if this is something that we want to do with this project. Go applications are commonly distributed on the GitHub releases page, like the goreleaser page or a small project that i'm working on.

When I suggested use goreleaser builds, I was thinking to make it easier get the binaries on the releases page. GOReleaser can build and package golang based builds in so many ways that makes it easier to publish the changes on this repo.

Sorry if I misunderstood something.

Please let me know if you guys wanna keep working on this PR.

You should be able to use a buildtag to remove the devicemapper support. We currently can build skopeo for Windows and MacOS. I am fine with getting Skopeo out to more sites where it is easer for people to access it.

Due to the CGO dependencies the build is only made on Linux 64 bits.

Sorry for getting OT - but how much work would it be to replace CGO with pure Go deps?

Looked at using skopeo a year ago and for me CGO was a show stopper.

The only CGO dependency can be eliminated by building with a buildtag, as long as you don't use devicemapper storage back end, which almost no one does.

A friendly reminder that this PR had no activity for 30 days.

I think this can be closed? @mtrmac @rhatdan wdyt?

I think so. We were discussing using a new tool for Windows support; introducing it for Linux, where we already have some working solutions and we aren’t familiar with this tool, seems not worth it.